In many information processing applications, a server application runs on a host or server computer in a distributed network. The server application provides processing services for client applications running on terminal or workstation computers operated by a multitude of users on the network. This is sometimes referred to as client/server computing.
In a form of client/server computing sometimes known as “distributed objects,” the server application includes a set of components conforming to an object-oriented programming (OOP) model, such as the Microsoft Component Object Model (COM) and Distributed Component Object Model (DCOM), the IBM System Object Model (SOM), the Object ‘Management Group’s Common Object Request Broker Architecture (CORBA), and others. Object-oriented programming generally has advantages in ease of programming, extensibility, reuse of code, and integration of software from different vendors and (in some object-oriented programming models) across programming languages.
One type of OOP environment is that of Web-based services. These services, due to their wide-spread use and technological progress, have developed at least two generations of Web services technology. The first-generation of Web services includes the use of open standards, universal access, rapid development, and continuous deployment. The second-generation Web services environment uses execution environments and tools that take care of infrastructures and operations so developers may focus on creating applications. These tools include the use of XML for universal representation, exchange and storage of all kinds of data, as well as for describing and manipulating component interfaces. One type of second-generation Web services environment for programming is offered by Microsoft Corporation and is known as the “.NET environment.” The .NET environment aims to make component construction and reuse of Web services applications easier than they have been previously.
The benefits of using a Web services language such as .NET common language technology may be clear, but they are less immediate and less certain than many programmers desire. In fact, the .NET environment suffers from certain limitations. Moreover, because of these limitations, programmers now using Active Server Pages (ASP), Visual Basic Script, Visual Basic and C++ skills are likely to find transitioning to the .NET environment platform particularly challenging. For example, VB.NET, which is one example of a .NET environment Visual Basic language, departs dramatically from earlier Visual Basic versions. It approaches object orientation, components and exception handling more like the newer C# language than does any previous Visual Basic language.
Still another limitation with the .NET environment has to do with the presentation layers created within the .NET environment. These presentation layers use the .NET ASP application, ASP.NET, and are very different from the pages written in the classic ASP framework. The classic ASP framework provides for application development of user interfaces or presentation layers. The ASP framework permits creating interactive pages as part of a Web-based application. To a degree, the ASP framework enables developers to separate programming logic from page design through the use of components that are called from the page itself. The ASP framework allows developers to separate content generation from layout by accessing components from the page, using a combination of tags and scripting to create dynamic Web pages.
The existing software to support the presentation layers created in the classic ASP framework cannot effectively interface with the .NET data access environment, ADO.NET. This is due to the ADO.NET environment's not supporting ActiveX Data Objects Database RecordSets (also called “ADODB.RecordSets”). The ADODB.RecordSet makes possible communication between a business tier and the data tier in database calls within the ASP framework. Unfortunately, ADODB.RecordSets are not supported in the ADO.NET environment, despite the fact that the classic ASP framework uses ADODB.RecordSets repeatedly for processing result sets from database calls. Many Internet applications have been developed using Microsoft ASP and Visual Basic version 6 (Visual Basic.6) components that employ ADODB.RecordSets. In fact, Microsoft ASP and Visual Basic.6 presently are somewhat ubiquitous languages for the Web services environment.
The newer .NET environment, which includes VB.NET (Visual Basic) and ASP.NET (Active Server Pages), do not support ADO.NET and ADODB.RecordSets equally. Instead of using ADODB.RecordSets, the ADO.NET framework uses an alternative structure, called the DataTable. Unfortunately, the DataTable does not directly interface with ADODB.RecordSets, and use of data within ADODB.RecordSets requires the use of a tool called “COM Interopt” to allow .NET components to access an ADODB.RecordSet. This slows execution times with each interaction between the classic ASP framework page and VB.NET component due to the need to call COM Interopt three times. A first call occurs so that the classic ASP framework can call the VB.NET component. A second call occurs to supply the ADODB.RecordSet to VB.NET. Still a third call loads the ADODB.RecordSet from an ADO.NET DataTable. The speed reductions that these calls impose on ASP applications may require many internet applications written in the classic ASP framework to be re-written to use ASP.NET, VB.NET, and ADO.NET for them to operate properly. To make this conversion, however, is so time-consuming and labor-intensive that very few applications can economically migrate to the .NET environment.